企業流程自動化不是新題目。
在 LLM 出現以前，我們已經有 BPM、Workflow Engine、Rule Engine、RPA、API Orchestration，以及大量「表單 → 規則 → 審核 → 執行」的系統。
所以當大家開始談 AI Agent，我第一個問題不是：
Agent 能不能幫我把流程全部自動化？
而是：
既然傳統 Workflow 已經能可靠地執行流程，Agent 到底應該插在哪裡？又有哪些地方不應該交給 Agent？
這個問題會貫穿接下來 30 天。
我想討論的不是「如何串一個 LLM API」，而是：
當具有不確定性的模型進入原本講求規則、狀態與稽核的企業流程後，我們要怎麼保留控制能力？
傳統 BPM / Workflow 系統很擅長處理明確流程。
例如：
表單
↓
規則判斷
↓
流程節點
↓
人工審核
↓
系統執行
它的優點通常是：
缺點也很明顯：當需求變得模糊、自然語言化、例外很多時，流程設計會迅速變複雜。
例如使用者說：
「幫我安排明天下午適合八個人、有視訊設備，而且盡量不要離大家太遠的共享空間。」
這裡其實同時包含：
如果全部用固定表單與 if/else 表達，可以做，但會很僵硬。
這就是 Agent 開始有價值的地方：處理模糊意圖、動態拆解任務、選擇工具與處理例外。
但這不代表我們應該把整個流程控制權都交出去。
Anthropic 在 Building Effective Agents 裡做了一個很實用的區分：
這個差異對企業系統非常重要。
如果一件事情有明確步驟、規則與責任邊界，Workflow 往往比 Agent 更容易預測與驗證。
如果一件事情的子任務無法事先完全預測，需要模型根據情境規劃，那 Agent 才更有優勢。
所以我不會把「Agentic」理解成：
讓模型越自由越好。
反而會把它理解成：
在需要彈性的地方給模型自主性，在需要正確性的地方保留 deterministic control。
假設一個 Agent 理解了使用者的需求，接下來要執行一個真實動作。
最危險的設計是：
User
↓
LLM
↓
直接寫 Database
因為「模型聽懂了」不等於：
更合理的做法會是：
Natural Language
↓
Agent / Intent
↓
Typed Tool Contract
↓
Policy / Authorization
↓
State / Transaction
↓
Human Approval（必要時）
↓
Commit
↓
Audit Trail
這也是本系列最核心的架構觀：
Agent 擅長理解意圖與處理模糊情境；流程系統負責規則、正確性與可追蹤性。
聊天系統很容易把「目前對話內容」當成狀態。
但真正的企業流程至少會有：
例如：
REQUESTED
↓
VALIDATED
↓
CANDIDATES_FOUND
↓
WAITING_APPROVAL
↓
COMMITTED
如果流程跑到 WAITING_APPROVAL 時對話中斷，隔天重新開啟系統，不應該只靠 LLM 從聊天紀錄「猜」目前狀態。
狀態應該被持久化，而且能被程式驗證。
這也是為什麼後續會花很多篇幅談：
這些聽起來不像 AI，但它們往往才決定 Agent 能不能真的進入企業流程。
另一個常見設計是把所有規則寫在 System Prompt：
你不能做 A。
你只有在 B 成立時才能做 C。
如果 D 發生要請使用者確認。
這可以拿來 Demo，但不適合當唯一的控制機制。
因為 Prompt 是模型輸入的一部分，不等於授權系統。
企業規則如果真的重要，應該有程式化的 enforcement：
Agent 提出動作
↓
Policy Engine / Business Rule
↓
Allowed / Denied / Needs Approval
例如：
LLM 可以協助判斷意圖，但授權不能只靠 Prompt。
很多人把 Human-in-the-loop 看成過渡方案：等模型更強，就可以把人工拿掉。
我不完全同意。
某些人工確認本來就是風險控制的一部分。
例如：
這些情況讓人確認，不代表自動化失敗。
反而是系統清楚知道：哪一個決策可以自動做，哪一個決策需要責任主體。
所以本系列不追求「100% 無人化」，而是追求：
Controlled Autonomy：可控的自主性。
為了讓討論具體，但又不碰任何真實企業內部流程，我會建立一套完全自建的 企業共享資源協調 Reference System。
它只是一個用來驗證架構的公開案例，會包含：
User
Resource
Availability
Request
Policy
Approval
Reservation / Allocation
Audit Log
使用者可以用自然語言提出需求，Agent 負責理解與規劃，但真正的操作必須經過 Tool、Policy、State 與必要的人工作業節點。
後續會故意測：
我要看的不是 Demo 能不能跑，而是這套流程在失敗時會不會失控。
我認為真正值得研究的不是「BPM 會不會被 Agent 淘汰」。
比較合理的方向反而是：
BPM / Workflow
負責狀態、規則、責任、可追蹤性
＋
Agent
負責理解意圖、規劃、工具選擇、模糊情境
↓
Agentic Workflow
如果兩者分工做對，企業流程可以同時得到：
這才是我認為 Agent 真正能創造業務價值的地方。
Day 1 先確立整個系列最重要的一句話：
Agentic Workflow 的關鍵不是讓 Agent 更自由，而是讓流程在引入 AI 之後仍然可控。
接下來不會先從框架開始，而會先建立一個完全公開、與任何真實公司系統無關的 Reference System。
因為只有案例固定，後面談 State、Policy、Idempotency、Transaction、Human-in-the-loop 與 Evaluation 才有共同基準。
下一篇：Day 02｜Reference System：用「企業共享資源協調」取代真實公司系統
為避免將實務經驗轉化成未授權的內部資訊，本系列所有流程、資料、Schema 與測試案例均以自建 Reference System 重現，不代表任何特定企業的實際系統設計。
iThome鐵人賽
看影片追技術